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REMARKS/ARGUMENTS 

I. Status of Claims 

Claims 1, 7, 12-18 and 23-28 are pending of which claims 1, 7, 17 and 23 are 
independent. 

II. Rejections under 35 U.S.C. S103 (a> 

Claims 1, 7, 12-18, and 23-28 re rejected under 35 U.S.C. 103(a) as being 
unpatentable over U.S. Patent Publication No. 2003/0221016 to Jouppi et al. 
(hereinafter- Jouppi), as applied to claims above, and further in view of U.S. Patent 
No. 7,145,919 to Krishnarajah et al. (hereinafter- Krishnarajah). Applicant 
respectfully traverse the rejection. 

i. Claim 1 

Claim 1 recites a method for performing Traffic Flow Template (TFT) filtering 
according to Internet Protocol (IP) versions in a mobile communication system, the 
method comprising the steps of: 

" extracting a first IP version address from a source second IP 
version address, wherein the second IP version address contains the 
first IP version address ; and 

generating TFT information using the first IP version address, 
wherein the TFT information contains an indication that the second IP 
version address contains the first IP version address ; and 

transmitting the TFT information to a Gateway GPRS (General 
Packet Radio Service) Support Node (GGSN)." (emphasis added). 

As reasoned in Applicant's February 15, 2008 response (hereinafter "the 
Previous Response") to the office action October 1 5, 2007, Jouppi does not disclose, 
teach, or suggest subject matter of "extracting a first IP version address from a source 
second DP version address, wherein the second IP version address contains the first IP 
version address" and "generating TFT information using the first IP version address, 
wherein the TFT information contains an indication that the second IP version address 
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contains the first IP version address", both of which are recited in claim 1. 
Nonetheless, the Examiner points to paragraph [0002], lines 9-12, paragraph [0039], 
lines 11-12 and paragraph [0006], lines 19-22 of Jouppi as disclosing the subject 
matter. 

With respect to paragraph [0039], lines 1 1-12, as the Examiner notes, it merely 
states that the TFT can comprise at least the following filter parameters: 

"source IP address (refers to the address of a peer device in an 
external network PDN), source gate, destination gate, DiffServ field 
(Differentiated Services), flow identifier (IPv6),, protocol number 
(IPv4V the next address field (IPv6) , security parameter index SPI in 
connection with the IPSec protocol, and according to the present 
preferred embodiment also an interface ID allocated by one or more 
mobile stations." (emphasis added). 

Hence, paragraph [0039], lines 11-12 of Jouppi merely generally describes 
what a TFT can comprise, which may include "flow identifier (IPv6), protocol number 
(IPv4)/ the next address field (IPv6)", and thus is irrelevant to "extracting a first IP 
version address from a source second IP version address, wherein the second IP 
version address contains the first IP version address" and "generating TFT 
information using the first IP version address, wherein the TFT information contains 
an indication that the second IP version address contains the first IP version address", 
both of which are recited in claim 1. Hence, the Examiner errs in concluding that 
paragraph [0039], lines 11-12 of Jouppi discloses the above-quoted claimed subject 
matter. 

With respect to paragraph [0002], lines 9-12 of Jouppi and paragraph [0006], 
lines 19-22 of Jouppi, paragraph [0002], lines 9-12 of Jouppi merely refers to primary 
PDP context and secondary PDP context as used in UMTS system, and paragraph 
[0006], lines 19-22 of Jouppi teaches, in verbatim, "[T]he filter functionality can be 
implemented by using not only an interface identifier but also other predetermined 
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parameters and/or conditions with which the packets or data flows can be identified." 
On the other hand, the Examiner argues that these two excerpts of Jouppi teach that 

"TFT contains one or more so-called packet filters. The filter 
functionality can be implemented by using not only an interface 
identifier but also other predetermined parameters and/or conditions 
with which the packets or data flows can be identified in the IPv6 
address structures. The Examiner views Filtering understood as 
Extracting ." 

Nonetheless, the Examiner's argument is not on the point of the subject 
matter recited in claim 1. Even if Jouppi does teach filtering functionality and 
filtering can be understood as extracting, as the Examiner agues, the Examiner's 
argument does not necessarily lead to the conclusion that Jouppi teaches the subject 
matter of "extracting a first IP version address from a source second IP version 
address, wherein the second IP version address contains the first IP version address" 
and "generating TFT information using the first IP version address, wherein the TFT 
information contains an indication that the second IP version address contains the first 
IP version address", both of which are recited in claim 1. This is because the 
Examiner's argument, at best, may only lead to the conclusion that Jouppi teaches that 
the packets or data flows identified in the IPv6 address structures, can be extracted. 
However, the subject matter recited in claim 1 does not just call for extracting 
data identified in the IPv6 address structures. Rather, the subject matter recited in 
claim 1 calls for "extracting a first IP version address from a source second IP version 
address, wherein the second IP version address contains the first IP version address" 
and "generating TFT information using the first IP version address, wherein the TFT 
information contains an indication that the second IP version address contains the first 
IP version address". Consequently, paragraph [0002], lines 9-12 of Jouppi and 
paragraph [0006], lines 19-22 of Jouppi do not disclose, teach, or suggest the above- 
quoted subject matter recited in claim 1 . 

Accordingly, contrary to the Examiner' assessment, paragraph [0002], lines 9- 
12, paragraph [0039], lines 11-12 and paragraph [0006], lines 19-22 of Jouppi do not 
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disclose, teach, or suggest "extracting a first EP version address from a source second 
IP version address, wherein the second IP version address contains the first IP version 
address" and "generating TFT information using the first IP version address, wherein 
the TFT information contains an indication that the second IP version address contains 
the first IP version address", both of which are recited in claim 1. 

In the "Response to Arguments" section, the Examiner appears to argue that 
col. 14, lines 38-57 and col. 11, lines 56-65 of Krishnarajah "solves both the problems 
of identification of packets based on IPv6 or IPv4 and compressing to reduce to 
computation load", and thus the combination of Jouppi and Krishnarajah teaches the 
subject matter recited in claim 1. Even if the Examiner's argument that "Krishnarajah 
solves both the problems of identification of packets based on IPv6 or IPv4 and 
compressing to reduce to computation load", is correct, it still has no bearing on 
whether Krishnarajah teaches or suggests the subject matter recited in claim 1. 

Specifically, "identification of packets based on IPv6 or IPv4" is neither the 
problem identified by Krishnarajah (or Jouppi), nor the problem that the claimed 
subject matter seeks to solve. The claimed subject matter relates to a scheme of 
generating specific TFT information using a first IP version address so as to 
drastically reduce computation load when a second IP version address contains the 
first EP version address. Hence, solving the problem of "identification of packets 
based on IPv6 or IPv4", as the Examiner argues that Krishnarajah teaches, is of no 
relevance to teaching the subject matter recited in claim 1. 

Further, the Examiner argues that Krishnarajah solves the problem of 
"compressing to reduce to computation load". It appears that the Examiner draws this 
conclusion largely from col. 1 1, lines 56-65, in which "header compression protocols" 
are discussed. However, protocols used for compressing a header are not the subject 
matter recited in claim 1 . As discussed above, the claimed subject matter relates to a 
scheme of generating specific TFT information using a first IP version address so as to 
drastically reduce computation load when a second IP version address contains the 
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first IP version address. Hence, solving the problem of "compressing to reduce to 
computation load", as the Examiner argues that Krishnarajah teaches, is also of no 
relevance to teaching the subject matter recited in claim 1. 



Accordingly, the Examiner's argument that Krishnarajah "solves both the 
problems of identification of packets based on IPv6 or IPv4 and compressing to 
reduce to computation load" is of no relevance to the subject matter recited in claim 1 . 
Consequently, even if the Examiner's arguments are taken as correct, the Examiner's 
arguments still cannot lead to the conclusion that Krishnarajah disclose, teach or 
suggest the subject matter recited in claim 1. 



On the other hand, nowhere does the cited col. 14, lines 38-57 of Krishnarajah 
teaches the subject matter recited in claim 1. Specifically, the cited section states the 
following: 



"In a UMTS architecture, the UE identifies a flow based on a 
set of parameters defined in a traffic flow template (TFT) which acts as 
a packet filter using filter parameters, like IP source/destination 
address, UDP source/destination address, etc., that are the same for an 
IP stream. The TFT is mapped to a specific GTP tunnel for which the 
PDP context was initiated. In the case where an IPv6 the flow label is 
used for flow identification, the UE initiates one TFT per flow and then 
maps it to the GTP tunnel . In the RTP header and destination option 
example implementations, only one TFT for the entire flow need be 
initiated since these example mechanisms do not modify any of the 
TFT parameters. Advantageously, introducing information in the IP 
flow label does not affect the TFT mechanism of directing each flow to 
the appropriate radio bearer. Although the flow label identify in the 
IPv6 header has been described here, similar identifiers in an IP packet, 
including in an IPv4 packet, may be used to indicate the subflows 1 of a 
particular CODEC stream in order to perform different treatment on 
those subflows, e.g., a TPS 2 field in the IPv4 header could be 
redefined. " (emphasis added). 



1 The term "subfiow" appears to refer to a subfiow of a radio access bearer (RAB). See col. 8, lines 62- 
64. An RAB can be split into several parts or subflows, each of which is associated with a radio bearer, 
a QoS class or treatment, and a fragmented payload. 

2 Although Krishnarajah does not give any meaning to the term "TOS", "TOS" appears to refer to the 
"Type of Service" field of a IPv4 packet. See page 20, lines 15-17 and Fig. 10 of the present 
application. 
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As can been seen, although the cited section of Krishnarajah refers to both 
IPv6 and IPv4, it merely discloses that IPv6 flow label is used for flow identification 
of different treatment to be performed on different flows (as taught earlier at col. 6, 
lines 59-62) and that, in the case of an IPv4 packet, identifiers similar to IPv6 flow 
label may be used to indicate the subflows of a particular CODEC stream in order to 
perform different treatment on those subflows, for example, a "Type of Service" 
(TOS) field in the IPv4 head could be redefined as those identifiers used for indicating 
different treatment to be performed on those subflows. In essence, the cited section of 
Krishnarajah teaches that, similar to an IPv6 packet's flow label, an IPv4 packet's 
"Type of Service" (TOS) field could also be used to indicate different treatment to be 
performed on subflows. Further, although the cited section of Krishnarajah also refers 
to TFT, it merely teaches that, in the case of a IPv6 packet, TFT can be initiated for 
each flow for the purpose of directing each flow to the appropriate radio bearer, in the 
context of performing different treatment on different flows. 

However, none of these above-mentioned teachings of the cited section of 
Krishnarajah is relevant to the subject matter recited in claim 1, and 
particularly to the subject matter of "extracting a first IP version address from a 
source second IP version address, wherein the second IP version address 
contains the first IP version address" and "generating TFT information using 
the first IP version address, wherein the TFT information contains an indication 
that the second IP version address contains the first IP version address". 

Specifically, nowhere in the cited section of Krishnarajah has any relevance to 
"extracting a first IP version address from a source second IP version address, wherein 
the second IP version address contains the first IP version address", as recited in claim 
1. The references to both "IPv6" and "IPv4" are merely for discussing that a similar 
scheme (related to performing different treatment on IPv6 flows and IPv4 subflows) 
can be applied to both an IPv6 packet and an IPv4 packet. 
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In addition, as discussed above, the reference to TFT in the cited section of 
Krishnarajah is limited to the teaching that, in the case of an IPv6 packet, TFT can be 
initiated for each flow for the purpose of directing each flow to the appropriate radio 
bearer, in the context of performing different treatment on different flows. This 
teaching, however, has no relevance to "generating TFT information using the first 
IP version address, wherein the TFT information contains an indication that the 
second IP version address contains the first IP version address", as recited in 
claim 1. 

Accordingly, the cited section of Krishnarajah, does not disclose the subject 
matter recited in claim 1, and particularly, the claimed steps of "extracting a first IP 
version address from a source second IP version address, wherein the second IP 
version address contains the first IP version address" and "generating TFT 
information using the first DP version address, wherein the TFT information contains 
an indication that the second IP version address contains the first IP version address". 

It is worth noting that it is hardly surprising that neither Jouppi nor 
Krishnarajah discloses, teaches, or suggests the subject matter recited in claim 1. As 
discussed in the Previous Response, the claimed subject matter is designed to 
overcome a load problem caused by the fact that with the prior art, 128-bit 
computations, rather than 32-bit computations, have to be performed against IPv4- 
embedded IPv6 addresses during the packet filtering process. By contrast, the scheme 
disclosed in Jouppi is designed to overcome a security problem caused by the 64-bit 
prefix of an IPv6 address allocated to a mobile station (see paragraph [0004] of 
Jouppi), and similarly, the scheme disclosed in Krishnarajah is designed to overcome 
the problem of inefficient use of the scarce radio bandwidth caused by the lack of 
differentiated treatment, as existed in the prior art, to bits of different priorities within 
a payload (see col. 2, lines 6-36). Hence, Jouppi and Krishnarajah are tackling 
problems that are very different from the load problem that the claimed subject matter 
seeks to solve. Consequently, it is of no surprise that their respective disclosure with 
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respect to IPv6, IPv4 and TFT are very different from the subject matter recited in 
claim 1. 

In sum, neither Jouppi nor Krishnarajah has any application to the problem the 
claimed subject matter seeks to solve. In particular, neither Jouppi nor Krishnarajah 
discloses, teaches, or suggests "generating TFT information using the first IP version 
address, wherein the TFT information contains an indication that the second IP 
version address contains the first IP version address", as recited in claim 1. 
Accordingly, claim 1 is allowable over Jouppi and Krishnarajah, and the rejection of 
claim 1 should be withdrawn. 

ii. Claims 7. 17 and 23 

Claims 7, 17 and 23 contain similar recitation to "generating TFT information 
using the first IP version address, wherein the TFT information contains an indication 
that the second IP version address contains the first IP version address", as recited in 
claim 1 . As discussed above, neither Jouppi nor Krishnarajah discloses, teaches, or 
suggests the above-quoted subject matter. Accordingly, claims 7, 17 and 23 are 
allowable over Jouppi and Krishnarajah, and the rejection of claims 7, 17 and 23 
should be withdrawn. 

iii. Claims 12-16, 18. and 24-28 

The rejection of claims 12-16, 18 and 24-28 should be withdrawn by virtue of 
their dependency from allowable claims 7 and 17. 
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III. Conclusion 

In view of the above, it is believed that this application is in condition for 
allowance and notice to this effect is respectfully requested. Should the Examiner 
have any questions, the Examiner is invited to contact the undersigned at the 
telephone number indicated below. 

Should any/additional fees be required, the Director is hereby authorized to 
charge the fees to Deposit Account No. 18-2220. 



Respectfully submitted, 




^fundong Ma 

Attorney for Applicant 
Reg. No. 61,789 



Roylance, Abrams, Berdo & Goodman, L.L.P. 
1300 19 th Street, N.W., Suite 600 
Washington, D.C. 20036 
(202) 659-9076 



Dated:. 



September 11.2008 
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